Personal computers have become so affordable that they are commonplace in homes and businesses. In addition, with the development of increasingly more intuitive ways to interact with computers, such as speech and handwriting recognition systems, even people uncomfortable using keyboards now can use a computer. As a result, computers are being used by more and more people, some of whom have fewer and fewer technical skills.
Computer systems also have become increasingly more complex. From a hardware standpoint, computers may use a wide range of storage media, multimedia input/output devices, wired and wireless network interfaces, and many other accessories. From a software perspective, expansive operating systems are used to manage processes needed to control the hardware devices, as well as to support numerous applications that might be running at the same time. As a result, diagnosing problems occurring in such systems has become at least as complex as the computer systems themselves.
FIG. 1A presents a flow diagram illustrating the logical steps followed in a conventional diagnostic process. The process may be conducted with the user following a manual, speaking via telephone with computer support personnel, or by engaging a troubleshooting program that steps the user through a diagnostic process.
Flow diagram 100 begins at block 102. At block 104, the user engages the computing system and continues to do so until, at decision block 106, a problem is encountered. If a problem has not been encountered, the flow diagram 100 takes a No branch back to after the start 102 of the flow diagram and before the user interacts with the computing system in block 104. Once the user determines a problem has occurred, at block 108, the user attempts to develop a verbal description of the problem. Unfortunately, accurately describing the problem is a nontrivial step.
For example, the problem might be that the user has opened a web browser with the intention of using a web-based e-mail service. The browser may start successfully, but may present the message “page not found.” An unsophisticated user may describe this problem, for example, by stating “my browser is not working,” “the network is down,” or “my e-mail is not available.” However, the browser may be working correctly, the network may not be down, and the user's e-mail may indeed be available. The problem actually may result from a number of causes, including a hardware failure, a network interface driver not being properly installed, a network cable becoming unplugged, or many other causes not covered by the user's description. Similarly, if a user is unable to get the computer system to read a disk, or print a document, despite what the user might think, the problem may not have anything to do with the disk or the printer.
Unfortunately, being able to describe the problem is important for any conventional diagnostic process. For example, if the user is using a manual, the user must develop some specific description of the problem to determine where in the index of the manual to search for a solution. Similarly, a user must be able to describe the problem to a computer support technician for the technician to be able to provide any assistance. Even using an automated trouble-shooting system, the user must be able to at least recognize or distinguish among verbal descriptions of possible problems to successfully engage the trouble-shooter. Thus, requiring a user to describe a problem may present a problem in itself.
Assuming a description of the problem has been successfully developed at block 108, an attempt is made at block 110 to identify the cause of the problem. This process also may be difficult. Again, taking the example of the “page not found” problem, based on even a reasonable description of the problem, there may be a number of possible causes that the user may have to try to solve the problem. When the description offered at block 108 is less refined or accurate, the more difficult it will be at block 110 to identify the cause of the problem.
At decision block 112, it is determined if one or more causes have been identified. If so, at block 114, the identified cause or causes are communicated to the user, and the process ends at step 116. If it is determined at decision block 112 that the cause has not identified, the process also ends at step 116, leaving the user without a solution.
To avoid depending on the user to accurately describe a problem, attempts have been made to automate the diagnostic process. One such approach has attempted to automate the process by identifying abnormal computer system events. In principle, once a tell-tale abnormal event is identified, the abnormal event indicates the cause of the problem.
FIG. 1B presents a flow diagram 120 illustrating the logical steps followed in a state-based problem solving process. Flow diagram 120 begins at block 122. At block 124, the user interacts with the computing system until, at decision block 126, a problem is encountered. If a problem has not been encountered, the flow diagram 120 takes a No branch back to after the start 122 of the flow diagram and before the user interacts with the computing system in block 124. Once a problem has occurred, at block 128, an abnormal state-identifying diagnostic routine is intiated. At a decision block 130, it is determined if a catalogued abnormal state has been identified. If not, the process ends at block 136. However, if such an abnormal state is identified at decision block 130, at block 132, one or more causes associated with the abnormal state are retrieved. At block 134, the one or more causes associated with the catalogued abnormal state are communicated to the user, and flow diagram 120 ends at block 136.
Unfortunately, state-based diagnostic methods have several shortcomings. First, accurately isolating single, abnormal events that indicate the cause of a problem may not be possible. Complex computer systems process many events that may be normal in one context but not another. Second, continually logging events for the occurrence of an abnormal state generates a significant quantity of data. Continually logging events may prove impractical. State logging could be initiated by a user who has experienced a problem in hopes that the user can recreate the problem, but the abnormal state may not recur. Third, an abnormal state may be empirically associated with numerous causes of numerous problems. Communicating to a user that he should attempt many corrective actions, most or all of which may prove useless, would not be satisfactory to most users.